Advances in semiconductor processing and design tools have enabled larger and larger systems to be integrated onto an integrated circuit (IC) chip. Millions of transistors may need to function properly for the system to operate as intended. Testing as many of these transistors as possible is critical to ensuring that end-user systems using the IC are reliable.
Creating test programs that provide adequate coverage of gates and transistors within the chip can be challenging. Most transistors within the chip do not connect directly to the limited number of external input-output I/O leads or “pins”. Creation of the test program may begin long before the first prototypes are manufactured.
FIG. 1 illustrates testing before and after first prototypes are available. Traditionally, test patterns were manually generated by the chip designer or test engineer who wrote stimuli (input values) and obtained expected outputs from a logic simulator. Test vectors that have both inputs and expected outputs were then loaded onto to automated tester 14, which applied physical signals to device-under-test 16, and compared outputs generated by device-under-test 16 to the expected outputs. Any mismatches were reported to the test operator and caused the chip to fail.
A probe card that contacts I/O pads on device-under-test 16 on a wafer could be connected to automated tester 14, or a packaged chip could be used as device-under-test 16. However, hundreds of thousands of dollars or more are often required to produce the first prototypes of device-under-test 16. It is often desirable to begin testing before the first prototypes are available.
Pre-first-silicon testing using the test program can begin using testbench 18. Testbench 18 is a simulator that receives the inputs from the test program, and generates outputs that can be compared to the expected outputs from the test program. Testbench 18 could be a hardware-based simulator such as a chassis filled with boards of programmable-logic chips that can be programmed with the logic that is eventually formed on the IC chip, device-under-test 16. Testbench 18 could also be a software-based simulator that executes on a computer. Quickturn (from Cadence) is a hardware emulation system used to test chips before first silicon. VCS (from Synopsys) and NC Verilog (from Cadence) are simulators that compile and simulate behavior RTL code.
As the design is updated, the logic simulated by testbench 18 may be updated, allowing the test engineer to adjust the test vectors to test the updated design. The test vectors may be adjusted to improve coverage of the chip's logic, and additional test vectors may be created before first silicon.
Rather than manually write test vectors, automated tools may be used to create test vectors. A random-number generator may create a series of input values for some of the inputs, such as values for a bus input. Self-checking test generators are one type of test-generation tool that also generate expected outputs. The input values are applied to a model of the device to be tested. The model predicts the expected outputs based on the input values and a current state of the model.
FIGS. 2A-E show self-checking test generation for a simple device. In FIG. 2A adder 10 generates an output that is the sum of two multi-bit inputs and a single-bit carry-in CIN. For example, when the multi-bit input values of 5 and 3 are applied and CIN is 0, the expected output of adder 10 is 8. Adder 10 could eventually be a block on a post-silicon device-under-test chip, but initially could be a model of the device to be tested.
In FIG. 2B, a self-checking test generator uses the model of the device block to generate test inputs and expected outputs. A self-checking test program generates random values to apply to the multi-bit inputs of adder 10, such as by calling a random-number function RND(A) or RND(B). The self-checking test generator accesses a model of adder 10 that predicts the expected output of adder 10, given the applied inputs. For example, the model of adder 10 predicts that the expected output is the sum of the two multi-bit inputs and the carry-in, or RND(A)+RND(B)+CIN.
The model for adder 10 could be called by the self-checking test-generating program, or could be written directly into the self-checking test program as shown in the simplified pseudo-code of FIG. 2C. In FIG. 2C, nested loops are used to generate a series of seed values A, B for the random number functions. The carry-in is set to 0. The model for adder 10 is expressed in the code statement:EXP_OUT==RND(A)+RND(B)+CIN 
The expected output for adder 10 is the sum of the random multi-bit values generated from seed values A, B, and the carry-in CIN.
In FIG. 2D, a common problem with self-checking test generator programs is shown. Self-checking test generators need to predict results of the generated test vectors. To predict results the self-checking test generators must model the device under test. Creating an exact software model of the design under test (DUT) is often a difficult undertaking. For complex designs with short schedules it is not practical to create an exact model. For these reasons it is practical to model the important design behaviors and leave the less important features un-modeled. FIG. 2D is an example where CIN from unmodeled logic 20 is not modeled by the self-checking test generator while adder 10 is modeled.
Since the expected output of adder 10 is the sum of the three inputs to adder 10, and one of the three inputs, CIN, is unknown because of unmodeled logic 20, the expected output of adder 20 is not able to be generated by the self-checking test generator program. This is a problem that must be solved for self-checking to be useful. Solving this problem is not as simple as ignoring the unknown output of this one adder. In most complex designs unknown outputs will propagate to many other parts of the design. It is possible to ignore all states that unknown logic may propagate to, but this may result in ignoring most of the design. Furthermore, this ignores many operations that are modeled that could have been checked if the inputs were known.
A fix to unknown signals is shown in FIG. 2E. Often it is possible to constrain the random test generation to ensure some states never occur. FIG. 2E depicts this case where CIN is forced to 0. It is easy to model the behavior “CIN=0” so that the complex modeling problem has been avoided.
There are several methods for constraining the generated test to force an input to a specific value. Occasionally it is as simple as disabling a mode of operation. Other times it requires creating additional constraints for the random test generation. For example, if negative-number sums are too difficult to model, then the test generator could be set to generate only positive-number inputs.
Constraining test generation to avoid a specific case is undesirable. While such constraints may solve the complex modeling problem, some logic may not be fully tested. This solution leaves a coverage hole where some of the design is not tested. These intentional coverage holes are dangerous because bugs may reside in the logic that is untested. To solve this coverage-hole problem, test engineers may create additional tests to ensure no area goes untested. This is undesirable additional work.
What is desired is a self-checking test generator program for use with unmodeled logic. A self-checking test generator program that handles unknown states from unmodeled logic is desirable. A more automated self-checking test generator program that does not require the test engineer to constrain test generation to produce known states is desirable.